Software 


@ Asynchronous Message 
Service Reference 
Implementation 

This software provides a library of 
middleware functions with a simple ap- 
plication programming interface, en- 
abling implementation of distributed 
applications in conformance with the 
CCSDS AMS (Consultative Committee 
for Space Data Systems Asynchronous 
Message Service) specification. 

The AMS service, and its protocols, 
implement an architectural concept 
under which the modules of mission sys- 
tems may be designed as if they were to 
operate in isolation, each one produc- 
ing and consuming mission information 
without explicit awareness of which 
other modules are currently operating. 
Communication relationships among 
such modules are self-configuring; this 
tends to minimize complexity in the de- 
velopment and operations of modular 
data systems. 

A system built on this model is a “soci- 
ety” of generally autonomous, inter-op- 
erating modules that may fluctuate 
freely over time in response to changing 
mission objectives, modules’ functional 
upgrades, and recovery from individual 
module failure. The purpose of AMS, 
then, is to reduce mission cost and risk 
by providing standard, reusable infra- 
structure for the exchange of informa- 
tion among data system modules in a 
manner that is simple to use, highly au- 
tomated, flexible, robust, scalable, and 
efficient. 

The implementation is designed to 
spawn multiple threads of AMS func- 
tionality under the control of an AMS 
application program. These threads en- 
able all members of an AMS-based, dis- 
tributed application to discover one an- 
other in real time, subscribe to messages 
on specific topics, and to publish mes- 
sages on specific topics. The query/ reply 
(client/server) communication model is 
also supported. 

Message exchange is optionally sub- 
ject to encryption (to support confiden- 
tiality) and authorization. Fault toler- 
ance measures in the discovery protocol 
minimize the likelihood of overall appli- 
cation failure due to any single opera- 
tional error anywhere in the system. The 
multi-threaded design simplifies pro- 
cessing while enabling application 


nodes to operate at high speeds; linked 
lists protected by mutex semaphores and 
condition variables are used for effi- 
cient, inter-thread communication. Ap- 
plications may use a variety of transport 
protocols underlying AMS itself, includ- 
ing TCP (Transmission Control Proto- 
col), UDP (User Datagram Protocol), 
and message queues. 

This work was done by Scott C. Burleigh of 
Santa Barbara Applied Research for NASA’s 
Jet Propulsion Laboratory. Further informa- 
tion is contained in a TSP ( see page 1 ). NPO- 
42814 

This software is available for commercial li- 
censing. Please contact Daniel Broderick of 
the California Institute of Technology at 
danielb@caltech.edu. Refer to NPO-42814. 


fa Zero-Copy Objects System 

Zero-Copy Objects System software 
enables application data to be encapsu- 
lated in layers of communication proto- 
col without being copied. Indirect refer- 
encing enables application source data, 
either in memory or in a file, to be en- 
capsulated “in place” within an unlim- 
ited number of protocol headers and/or 
trailers. 

Zero-copy objects (ZCOs) are abstract 
data access representations designed to 
minimize 1/ O (input/ output) in the en- 
capsulation of application source data 
within one or more layers of communi- 
cation protocol structure. They are con- 
structed within the heap space of a “Sim- 
ple Data Recorder” (SDR) data store to 
which all participating layers of the stack 
must have access. Each ZCO contains 
general information enabling access to 
the core source data object (an item of 
application data), together with (a) a 
linked list of zero or more specific “ex- 
tents” that reference portions of this 
source data object, and (b) linked lists of 
protocol header and trailer capsules. 
The concatenation of the headers (in as- 
cending stack sequence), the source 
data object extents, and the trailers (in 
descending stack sequence) constitute 
the transmitted data object constructed 
from the ZCO. 

This scheme enables a source data ob- 
ject to be encapsulated in a succession of 
protocol layers without ever having to be 
copied from a buffer at one layer of the 
protocol stack to an encapsulating 
buffer at a lower layer of the stack. For 


large source data objects, the savings in 
copy time and reduction in memory 
consumption may be considerable. 

This work was done by Scott C. Burleigh of 
ACRO for NASA’s Jet Propulsion Laboratory. 
Further information is contained in a TSP 
(see page 1 ). 

This software is available for commercial li- 
censing. Please contact Daniel Broderick of 
the California Institute of Technology at 
danielb@caltech.edu. Refer to NPO-41627. 


Delay and Disruption 
Tolerant Networking 
MACHETE Model 

To verify satisfaction of communica- 
tion requirements imposed by unique 
missions, as early as 2000, the Com- 
munications Networking Group at the 
Jet Propulsion Laboratory (JPL) saw the 
need for an environment to support in- 
terplanetary communication protocol 
design, validation, and characterization. 
JPL’s Multi-mission Advanced Com- 
munications Hybrid Environment for 
Test and Evaluation (MACHETE), de- 
scribed in ’’Simulator of Space Com- 
munication Networks” (NPO-41373) 
NASA Tech Briefs, Vol. 29, No. 8 (August 
2005), p. 44, combines various commer- 
cial, non-commercial, and in-house cus- 
tom tools for simulation and perform- 
ance analysis of space networks. The 
MACHETE environment supports or- 
bital analysis, link budget analysis, com- 
munications network simulations, and 
hardware-in-the-loop testing. As NASA 
is expanding its Space Communications 
and Navigation (SCaN) capabilities to 
support planned and future missions, 
building infrastructure to maintain serv- 
ices and developing enabling technolo- 
gies, an important and broader role is 
seen for MACHETE in design-phase 
evaluation of future SCaN architectures. 

To support evaluation of the develop- 
ing Delay Tolerant Networking (DTN) 
field and its applicability for space net- 
works, JPL developed MACHETE mod- 
els for DTN - Bundle Protocol (BP) and 
Licklider/Long-haul Transmission Pro- 
tocol (LTP). DTN is an Internet Re- 
search Task Force (IRTF) architecture 
providing communication in and/or 
through highly stressed networking en- 
vironments such as space exploration 
and battlefield networks. Stressed net- 
working environments include those 
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with intermittent (predictable and un- 
known) connectivity, large and/or vari- 
able delays, and high bit error rates. To 
provide its services over existing domain 
specific protocols, the DTN protocols 
reside at the application layer of the 
TCP/IP stack, forming a store-and-for- 
ward overlay network. The key capabili- 
ties of the Bundle Protocol include cus- 
tody-based reliability, the ability to cope 
with intermittent connectivity, the abil- 
ity to take advantage of scheduled and 
opportunistic connectivity, and late 
binding of names to addresses. 

Internet standards are published in 
Request For Comments (RFCs), and 
the Bundle Protocol and LTP are de- 
scribed in RFC 5050 and RFC 5326, re- 
spectively. BP provides the store-carry- 
forward, custody transfer and naming 
capabilities of the DTN, while LTP was 
specifically developed for long-delay 
links. LTP allows for “red” and “green” 
data portions in a single session, where 
the red data portion uses retransmis- 
sion and the green data portion does 
not. Unlike common Internet retrans- 
mission protocols, LTP adds the ability 
to suspend and resume timers when the 
link’s status changes. On occasion, the 
models are extended to include non- 
standard experimental features for vali- 
dating project-specific performance or 
behavioral requirements. For instance, 
unlike standard simulation models, the 
BP model supports external traffic in- 
jection, which was used to verify correct 
behavior of the SharedNet middleware 
over DTN protocols and described at 
the SMC-IT 2006 conference (Second 
International Conference On Space 
Mission Challenges For Information 
Technology). The MACHETE LTP 
model supports all standard functions 
of LTP along with an optional priority- 
aware queuing system to prevent lower 
priority from blocking higher-priority 
traffic arriving later. 

Furthermore, MACHETE contains 
Consultative Committee for Space Data 
Systems (CCSDS) protocol standards, 
such as Proximity-1, Advanced Orbiting 
Systems (AOS), Packet Telemetry/ 
Telecommand, Space Communications 
Protocol Specification (SCPS), and the 
CCSDS File Delivery Protocol (CFDP). 
So, with the addition of DTN protocol li- 
braries interplanetary network, engi- 
neers at JPL can characterize future 
space network performance trade-offs. 

This work was done by John S. Segui, Esther 
H. Jennings, and Jay L. Gao of Caltech for 
NASA’s Jet Propulsion Laboratory. For more 
information, contact iaoffice@jpl. nasa.gov. 


This software is available for commercial li- 
censing. Please contact Daniel Broderick of 
the California Institute of Technology at 
danielb@caltech. edu. Refer to NPO-4341 0. 


A Contact Graph Routing 

Contact Graph Routing (CGR) is a dy- 
namic routing system that computes 
routes through a time-varying topology 
of scheduled communication contacts 
in a network based on the DTN (Delay- 
Tolerant Networking) architecture. It is 
designed to enable dynamic selection of 
data transmission routes in a space net- 
work based on DTN. This dynamic re- 
sponsiveness in route computation 
should be significantly more effective 
and less expensive than static routing, 
increasing total data return while at the 
same time reducing mission operations 
cost and risk. 

The basic strategy of CGR is to take 
advantage of the fact that, since flight 
mission communication operations are 
planned in detail, the communication 
routes between any pair of “bundle 
agents” in a population of nodes that 
have all been informed of one another’s 
plans can be inferred from those plans 
rather than discovered via dialogue 
(which is impractical over long one-way- 
light-time space links). Messages that 
convey this planning information are 
used to construct “contact graphs” 
(time-varying models of network con- 
nectivity) from which CGR automatically 
computes efficient routes for bundles. 
Automatic route selection increases the 
flexibility and resilience of the space net- 
work, simplifying cross-support and re- 
ducing mission management costs. 

Note that there are no “routing tables” 
in Contact Graph Routing. The best 
route for a bundle destined for a given 
node may routinely be different from the 
best route for a different bundle destined 
for the same node, depending on bundle 
priority, bundle expiration time, and 
changes in the current lengths of trans- 
mission queues for neighboring nodes; 
routes must be computed individually for 
each bundle, from the Bundle Protocol 
agent’s current network connectivity 
model for the bundle’s destination node 
(the contact graph) . Clearly this places a 
premium on optimizing the implementa- 
tion of the route computation algorithm. 
The scalability of CGR to very large net- 
works remains a research topic. 

The information carried by CGR con- 
tact plan messages is useful not only for 
dynamic route computation, but also for 
the implementation of rate control, con- 


gestion forecasting, transmission epi- 
sode initiation and termination, timeout 
interval computation, and retransmis- 
sion timer suspension and resumption. 

This work was done by Scott C. Burleigh of 
Caltech for NASA’s Jet Propulsion Laboratory. 
Further information is contained in a TSP 
(see page 1 ). 

This software is available, for commercial li- 
censing. Please contact Daniel Broderick of 
the California Institute of Technology at 
danielb@ccdtech.edu. Refer to NPO-45488. 


Parallel Eclipse Project 
Checkout 

Parallel Eclipse Project Checkout 
(PEPC) is a program written to leverage 
parallelism and to automate the check- 
out process of plug-ins created in Eclipse 
RCP (Rich Client Platform). Eclipse 
plug-ins can be aggregated in a “feature 
project.” This innovation digests a fea- 
ture description (xml file) and automat- 
ically checks out all of the plug-ins listed 
in the feature. This resolves the issue of 
manually checking out each plug-in re- 
quired to work on the project. To mini- 
mize the amount of time necessary to 
checkout the plug-ins, this program 
makes the plug-in checkouts parallel. 
After parsing the feature, a request to 
checkout for each plug-in in the feature 
has been inserted. These requests are 
handled by a thread pool with a config- 
urable number of threads. By checking 
out the plug-ins in parallel, the checkout 
process is streamlined before getting 
started on the project. 

For instance, projects that took 30 
minutes to checkout now take less than 
5 minutes. The effect is especially clear 
on a Mac, which has a network monitor 
displaying the bandwidth use. When 
running the client from a developer’s 
home, the checkout process now satu- 
rates the bandwidth in order to get all 
the plug-ins checked out as fast as possi- 
ble. For comparison, a checkout process 
that ranged from 8-200 Kbps from a de- 
veloper’s home is now able to saturate a 
pipe of 1.3 Mbps, resulting in signifi- 
cantly faster checkouts. 

Eclipse IDE (integrated develop- 
ment environment) tries to build a 
project as soon as it is downloaded. As 
part of another optimization, this in- 
novation programmatically tells 
Eclipse to stop building while check- 
outs are happening, which dramati- 
cally reduces lock contention and en- 
ables plug-ins to continue 
downloading until all of them finish. 
Furthermore, the software re-enables 
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